Local Area Networks (LANs), Wide Area Networks (WAN), and the Internet connect businesses and people across the world. Networks typically use routers to route data to the nodes or connection points of the network. Routers are generally specialized computers that forward messages to their respective destinations along many possible pathways via, what the router may calculate as, an effective and efficient route. As traffic increases, congestion may develop along any one or several such possible routes, communication links go down or routers may fail. The router may then change preferred routing schemes to accommodate the congestion or network failures (dead communication link or router).
Routers generally have input and output ports, for receiving and sending messages/packets, a switching fabric of some kind, and a routing processor. During operation, the routing processor controls routing hardware/software processes that examine the header information of the message/packet and find the address where the data is being sent. The router will then generally compare the network address against an internal database of addresses, known as a routing table, that maintains a list of possible routes to that destination address. Based on the particular Internet Protocol (IP) address to which the message/packet is addressed, the message/packet is sent to the destination, whether the destination is the final destination or whether it is the next router in the destination path.
The routers within a particular autonomous system (AS) may exchange routing information internally (i.e., intra-domain routing) using any one of a variety of accepted routing protocols, such as Routing Information Protocol (RIP), Open Shortest Path First protocol (OSPF), Intermediate System to Intermediate System (ISIS), or the like. Routers that participate in inter-domain routing (i.e., routing information exchanged between different domains or AS) typically exchange information using Border Gateway Protocol (BGP). BGP usually runs over a connection-oriented transport protocol, such as Transport Control Protocol (TCP). Using this transport connection, BGP routers may exchange BGP messages (i.e., update messages with announcements or withdrawals of Internet Protocol (IP) prefixes, keep alive messages, and the like) that allow them to create and update their routing tables. It should be noted that an IP prefix is an IP address associated with a mask of valid bits. For example, a prefix, 130.29.0.0/16, means only that the most significant 16 bits are valid.
In managing networks and network connections it is useful to monitor the routing tables. By analyzing the changes in the routing tables, the state of the network or networks may be determined. For example, when a communication link or a router stop operating in particular areas of the network, the prefixes with paths that include those failed networking elements may be withdrawn or deleted from the routing tables. Routing tables may be monitored directly using Simple Network Management Protocol (SNMP), Telnet, and/or peer sessions directly with the monitored router. A user may then access the routing information from the monitored router either directly through the SNMP/Telnet connections or indirectly through a Web server. The Web server generally obtains the routing information from the SNMP/Telnet session but presents the information through a Web access point. Web access is typically implemented as “Looking Glass” software applications that provide a “looking glass” into the routing table of the target router. Because the monitoring entity does not establish a direct connection to the router, Web server access generally provides a much more securable means for viewing the routing information than SNMP/Telnet. Therefore, SNMP/Telnet access is typically limited to trusted users.
Internet Service Providers (ISPs) generally maintain AS that may be further interconnected with various other AS. Public exchange points are the areas where multiple such ISPs exchange routing and traffic information through routers along the edges of the AS, referred to as edge routers. Historically, each edge router exchanges the routing information with each other edge router both within its AS and within the bordering AS. This process leads to many BGP sessions/connections to be made between the edge servers. The set of these connections is referred to as the BGP mesh. Because each router would typically need to connect with each other router, R2 BGP connections generally result, where R is the total number of routers in the mesh. One method that has been implemented to overcome the complexity of this BGP mesh is to deploy route servers (RS).
An RS is a software application running on a router or another computer connected to the network that communicates and exchanges route information with the AS′ edge servers. Under the RS′ routing policies, routing information may be exchanged with any other requesting router, including routers of the neighboring AS that are provided for in the routing policy. By providing the more centralized access point for exchanging and obtaining routing information, the number of connections or BGP sessions is substantially reduced. Instead of R2 BGP connections/sessions, because each router only needs to connect with the RS, there is typically only R connections/sessions. Using an RS also generally allows the user to capture a more complete picture of the BGP updates instead of a mere snapshot of the routing information base (RIB) that is obtained through the direct access methods. RS are typically deployed at the edges of the AS, where communication may occur with routers external to the known network.
Another means for centralizing access to routing information is using a Route Reflector (RR). Like an RS, an RR is a software application running on a router or another computer connected to the network that communicates and exchanges route information. However, RR do not generally have routing policies that dictate which requesting routers or entities can or cannot access the routing information. RR basically repeats all of the routing information that it has to any accessing entity. RR are primarily used to reduce the mesh within AS, while RS are generally used to allow exchange routing information between multiple AS.
The problem with the current techniques is that they each require a BGP session with the monitored router, RS, and/or RR. Establishing and running a BGP session with the monitored router drains the monitored router's central processing unit (CPU) cycles. A router's performance generally degrades as the number of open BGP sessions increases. Therefore, because an RS is typically configured as a peer in every monitored router's configuration file, these techniques are generally not very well-suited for passively monitoring routing information. The establishment of such BGP sessions is very invasive creating a management problem for the routers. In addition, if, for some reason, overloaded RS begin crashing, the monitoring routers attempt to reestablish the BGP sessions. Reestablishing the BGP sessions causes extensive updates to occur because the monitored router sends all of its routing information to the RS again. For edge routers, this updating may result in the monitored router sending over 100,000 prefixes to the RS.
Additionally, gathering routing information in a session between the monitoring system and the monitored router only gathers the information that relates to the connection between those two devices. If a BGP session between a monitored router and another router goes down, there is generally no way to determine what caused the failure. As the BGP session goes down, the monitored session may provide a flood of withdraw signals, as well as multiple announcements of IP prefixes arriving as a result of a BGP session going down. However, there is no way to determine whether the problem is with the TCP session or BGP session. Additionally, the monitored system maybe overloaded causing the system to stop sending “keep alive” message to monitored router. Ceasing the “keep alive” messages may then cause a BGP session reset by the monitored router resulting again in a flood of prefix announcements when the BGP session is reestablished, as discussed above. Consequently, the announcements caused by reestablishing the BGP session may lead to further overloading of other monitored stations/routers. Overstressed monitored stations could then cause BGP sessions to fail with other monitored routers creating a domino effect of reestablishing multiple BGP sessions.
Many current monitoring systems utilize public domain routing software, such as Zebra, to obtain and monitor routing information. Zebra is a routing software that captures BGP traffic via established BGP sessions with monitored routers and reconstructs routing tables based on provided routing information. Zebra may be used to implement a router, RS, or RR; therefore, it leverages that functionality to obtain the routing information. Zebra may establish BGP sessions with one or more of the routers, route servers, or Route Reflectors and obtain routing information. Thus, monitoring the router using Zebra also decreases the efficiency of that router.
Additional means for gathering routing information have been employed using line taps or packet sniffers. Taps and sniffers are devices that actually tap into a communication line between two or more routers. These devices essentially eavesdrop on the communication taking place between different routers. Such tapping methods typically capture the routing information and display it as formatted BGP data. Similar tapping methods are used in Network Intrusion Detection Systems (NIDS), which use sophisticated analysis engines to detect system attacks/intrusions including attacks made at the BGP level. While such tapping/sniffing methods allow for passively capturing or recovering routing information without establishing a BGP session with the monitored routers, issues such as data security and ability to trap and compile information for all of the data passing through the communications lines arise.